En los últimos dos años, platform engineering ha emergido como disciplina distinta de DevOps y SRE. La idea central: en lugar de que cada equipo construya y operativice su propia infraestructura, un equipo dedicado ofrece una plataforma interna (IDP — Internal Developer Platform) como producto. El objetivo es que los equipos de producto entreguen valor rápido sin convertirse en expertos en Kubernetes, Terraform o el sistema de CI.
El problema que resuelve
A partir de cierta escala (20+ servicios, 50+ desarrolladores), el patrón “cada equipo gestiona su stack” se vuelve caro:
- Duplicación. Cada equipo resuelve independientemente deployment, observabilidad, secrets, auth.
- Fricciones cognitivas. Un desarrollador backend pasa 30-40% del tiempo en tareas de infraestructura que no son su especialidad.
- Inconsistencia operativa. Problemas similares resueltos de formas distintas complican incidentes y auditorías.
- Movilidad reducida. Mover un ingeniero entre equipos requiere reaprender su toolchain.
IDPs abordan esto consolidando lo común detrás de una interfaz unificada, sin limitar la flexibilidad donde importa.
Qué compone un IDP
Un IDP maduro típicamente incluye:
- Portal de desarrollador: UI unificada donde ver servicios, crearlos, gestionarlos. Backstage de Spotify es la referencia open-source.
- Catálogo de servicios: inventario con metadata (equipo responsable, dependencias, SLOs, docs). Es la “base de datos” del IDP.
- Golden paths: caminos pre-construidos para casos comunes (crear un microservicio nuevo, desplegar a staging, configurar observabilidad). Más que tutoriales — son templates que reducen la creación a un comando.
- Self-service: los equipos de producto pueden aprovisionar recursos sin tickets manuales al equipo de plataforma.
- Observability por defecto: todo servicio nuevo arranca con métricas, logs y trazas.
- Guardrails, no gates: políticas que permiten avanzar pero alertan o previenen errores conocidos.
Backstage como referencia
Backstage, open-sourced por Spotify en 2020, es el componente más visible del ecosistema. Funciones:
- Software catalog: YAML describe servicios, su ownership, docs, y relaciones. Una entrada por entidad (servicio, librería, website, infraestructura).
- Plugins: ecosistema de ~100+ plugins (CI/CD status, Kubernetes, monitoring, docs) que viven en el mismo portal.
- TechDocs: documentación como código, renderizada dentro del portal.
- Scaffolder: generador de nuevos componentes a partir de templates (crear un servicio Spring Boot con observabilidad y CI en un clic).
En 2023, Backstage es la base de docenas de IDPs internos en empresas grandes, aunque requiere inversión sustancial para adaptarlo al contexto propio.
Golden paths: el valor central
Un golden path responde: “Quiero crear un microservicio nuevo — ¿cuál es la forma recomendada aquí?”. La respuesta debería ser un template que genera:
- Repositorio con estructura estándar.
- Dockerfile y CI configurado.
- Manifiestos Kubernetes con límites de recursos y health checks.
- Dashboard de Grafana pre-creado.
- Alerta básica de error rate sobre SLO.
- Integración con el sistema de auth de la empresa.
Lo clave: el golden path no es mandatorio. Los equipos pueden desviarse cuando lo necesiten. Pero el “camino feliz” es claro y está tan subvencionado que la mayoría lo sigue por defecto.
Cuándo invertir en platform engineering
No todos los equipos necesitan un IDP. Señales de que es momento:
- Más de 30-50 desarrolladores trabajando en servicios interconectados.
- Duplicación visible entre equipos en configuración, deployment, observabilidad.
- Incidentes cuyo root cause es “cada equipo lo hace distinto”.
- Onboarding lento — más de 2 semanas para que un nuevo ingeniero pueda desplegar algo útil.
Para equipos más pequeños, la inversión en IDP suele ser prematura. Mejor empezar con buenas prácticas y scripts compartidos, formalizar plataforma cuando la escala lo justifique.
Antipatrones a evitar
Tres errores que se ven repetidamente:
- Platform team = “DevOps team renombrado”. Si solo haces infraestructura sin tratar al desarrollador como cliente, no has hecho platform engineering.
- IDP como gate, no como path. Forzar al equipo de producto a pasar por el IDP bloquea innovación. Ofrecer como opción claramente mejor es distinto.
- Construir todo custom. Backstage + plugins + algunas integraciones es suficiente para la mayoría. Reinventar la rueda rara vez justifica el coste.
Ver también cómo aplicar SRE sin ser Google — platform engineering complementa SRE: SRE opera lo que platform construye.
Conclusión
Platform engineering en 2023 es disciplina madura para organizaciones de cierta escala. Un IDP bien diseñado libera tiempo de equipos de producto, consolida prácticas, y reduce incidentes operativos. Pero solo si se trata como producto real con usuarios reales (los ingenieros internos) y no como proyecto de infraestructura más.
Síguenos en jacar.es para más sobre platform engineering, SRE y productividad de desarrollo.
